By way of brief background, “push” architectures for services, including applications, facilitate server initiated requests for an event transaction. These can be through a constantly open IP connection. Push architectures can be contrasted with “pull” architectures that initiate event transmission requests by a receiver or client, e.g., typically across a temporary IP connection. Common examples of push-enabled services can include instant messaging, and synchronous conferencing. Email systems can also employ push-enabled services.
Modern “push” architectures may not always be true push systems but can emulate push-architectures by employing push, pull, polling, and push-notification features. As an example, many smartphones employ a push notification service that can receive notifications from servers of application events on an constantly open IP connection. These notifications of events can be substantially smaller than the application events themselves. In response to the device receiving the push-notification, the device can then poll the related application service to receive the application event. The push-notifications can be managed by notification centers.
Push-notifications can be pushed to devices on different paths than paths that are used to access a service event or application event. For instance, push-notifications can be pushed over cellular technologies while access to the service event can be by a wireless connection, e.g., a Wi-Fi type connection, or a wired connection, e.g., an Ethernet connection. Push-notifications can trigger specific types of alerts to notify users of service events, e.g., audible alerts, vibratory alerts, banners, badges, etc.